There are essentially four main categories of events:
窶｢ 窶彜end data窶 events
窶｢ 窶彝eceive data窶 events
窶｢ 窶彜end and receive data窶 events
窶｢ 窶弋rigger action窶 events
A 窶彜end data窶 event adds all the input values it gets from its predecessors, and sends this sum to its target application. Nothing (i.e., the number zero) is passed on to its successors.
A 窶彝eceive data窶 event sends a request for a certain result (a single real number) to its target application and passes this result on to its successors.
A 窶彜end and receive data窶 event adds all the input values it gets from its predecessors, and sends this sum together with a request for a certain result (a single real number) to its target application and passes this result on to its successors. The received result is typically some function of the input sum.
A 窶弋rigger action窶 event simply asks its target application to carry out a certain action, e.g., recalculate a spreadsheet. Nothing (i.e., the number zero) is passed on to its successors.
When you include events in a model, a good way to start is to find out which of the above categories the different events belong to, and in which order their respective messages should be sent.
To illustrate this, we consider a simple example. Suppose you want your model to feed random numbers into a certain cell in a spreadsheet. For each such number, you want the spreadsheet to be recalculated. Finally after each recalculation, you want to transfer the value of a specific cell back to DynRisk.
As a 窶徨andom number generator窶 we use a node which we call 窶弭窶. The number we get back from the spreadsheet, will be passed on to a node called 窶弸窶.
We observe that there are three different messages we need to send to the spreadsheet:
窶｢ 窶彜end X窶
窶｢ 窶彝ecalculate窶
窶｢ 窶彝eceive Y窶
[If the spreadsheet is configured to do automatic recalculation, we could of course skip the second message, but for the purpose of the argument, we assume that this is not the case here. Indeed, in cases where you feed many values into a large complex spreadsheet, you may save a lot of time by switching off automatic recalculation, and then send a recalculate message after the last number has been transferred.]
To accomplish this, we will use three events, named 窶彜end X窶, 窶彝ecalculate窶 and 窶彝eceive Y窶 respectively. Together with the two nodes, 窶弭窶 and 窶弸窶, we then have a model with five objects.
Now, to get correct results, it is obvious that the three messages need to be sent in the following order: 窶彜end X窶, 窶彝ecalculate窶, 窶彝eceive Y窶. Moreover, before we can send the value of 窶弭窶, we need to calculate this value, and before we can calculate 窶弸窶, we need to receive this value from the spreadsheet.
When DynRisk calculates a model, the model objects are always calculated in an order which respects the directions of the edges. If there is a directed path from one object to another, then the first object will always be calculated before the second.
This means that to get correct results in our case, we need to add edges to the model such that we get a directed path starting at 窶弭窶, passing through 窶彜end X窶, 窶彝ecalculate窶 and 窶彝eceive Y窶 in that order, and ending at 窶弸窶.
Considering the categories of the three events, we see that 窶彜end X窶 is a 窶彜end data窶 event, 窶彝ecalculate窶 is a 窶弋rigger action窶 event, and 窶彝eceive Y窶 is a 窶彝eceive data窶 event. This implies that we have the following data flow through our model:
窶｢ 窶弭窶 -> 窶彜end X窶 : The value of 窶弭窶
窶｢ 窶彜end X窶 -> 窶彝ecalculate窶 : 0
窶｢ 窶彝ecalculate窶 -> 窶彝eceive Y窶 : 0
窶｢ 窶彝eceive Y窶 -> 窶弸窶 : The value of 窶弸窶
We notice that the values passed along the two intermediate edges, are just dummy values. They are not used at all in the calculations. We still need these edges to ensure that everything happens in the right order.
Finally, note that we cannot skip 窶弸窶. Why? Because DynRisk does not allow events to be stored on file. Thus, we have to pass the value over to a node.
In fact, if we skipped 窶弸窶 in the diagram, and then tried to run a simulation on the model, then only 窶弭窶 would be simulated. No messages will ever be sent to the spreadsheet!
In order to determine which objects that need to be calculated during a simulation, DynRisk starts out with the objects which are selected to be stored on file. If 窶弸窶 is deleted from the model, only 窶弭窶 could be stored. DynRisk then continues by following the edges backwards through the model, and includes all objects found along the way. In our case, 窶弭窶 has no predecessors. Thus, without 窶弸窶, only 窶弭窶 will be included in the simulation.
